Workload management in client-server enterprise systems is now common place. In a workload managed system a groups of server processes (workgroups) are set up such that each server process in the workgroup has similar capabilities. This enables every server process in the workgroup to process a given request (or message) on behalf of a client. When a client sends a request to a workgroup, a workload management unit decides which server process in the workgroup to assign the request to. This is usually based on a user defined policy which could, for example, be least busy or round robin. This hopefully ensures that server process resources are used efficiently and clients are much less likely to suffer poor responses due to bottlenecks caused by a single server process simultaneously running requests for many clients.
A typical workload managed system is shown in FIG. 1. The system comprises many clients (10) communicating, over a network (11), with a workload management unit (12). The workload management unit (12) distributes work, over the network (11), to a workgroup comprising two server processes, each server processes running in a server (13 and 14). When a client makes a request the workload management unit receives the request and selects a server process to allocate it to. The workload management unit may be part of one or more server processes that make up the workgroup.
Ideally in such systems the workload management unit is free to select a server process, based on the chosen policy, for each client request received as this enables better distribution of work. However this is not always possible. For example, in one request a client can create an object instance, in a given server process, which contains data that the client requires access to in subsequent requests. For the client to work correctly the workload distribution unit must ensure that the client obtains access to the correct object instance. This can be done either by maintaining some element of client-server affinity, for the lifetime of the client, that ensures a client returns to the server process in which an object instance was created when the client next requires access to it, or by enabling an object instance to move between server processes, without loss of state, between requests. If the only option available is client-server affinity, workload distribution will be adversely affected because it may only be possible to workload manage a subset of a clients requests, and it is difficult, if not impossible, to predict the load a client is likely to impose on a server process when the client-server affinity is fixed.
It is therefore preferable to enable objects to move server processes between requests. This is fairly straightforward for objects that maintain state data in a database (or file) as the object instance can access the database or file from any server process in the workgroup. As a result the object instance can be moved to any server process although, if it is taking part in transaction, the object cannot be moved until the transaction is completed, as database changes made during the transaction will only be hardened to the database when the transaction commits. However, if an object instance holds the state data in volatile memory, it cannot easily be moved between server processes. This is because volatile memory is only normally accessible from the server process that allocated it. As a result, if a client uses this type of object, client-server affinity is enforced and workload management is subject to the discussed limitation.
This is can be illustrated by looking at a particular programming model employed in such workload managed client-server enterprise systems. A good example is the industry standard Enterprise JavaBeans™ (EJB™) programming model. This model is fully defined in the Enterprise JavaBeans v1.1 Specification, available from Sun Microsystems, Inc., included here by reference. Some features of this specification are now described for clarity
The Enterprise JavaBeans v1.1 Specification describes classifications of EJBs (objects), that run in server processes, based on their functionality. Two classifications are session beans and entity beans. Session beans typically: execute on behalf of a client; can access a database but do not represent a database; are short-lived; and are not recoverable. Entity beans typically: are accessible to multiple clients; represent a database; can be long lived; and are recoverable. Session beans are further classified as either stateless or stateful. A stateless session bean instance does not contain a conversational state such that a client can use any instance of the session bean. However, a stateful session bean instance does contain conversational state that a client may require repeated access to. As a result a client must always access an instance of a stateful session bean with the required state. As this state is at least partially held in volatile memory this usually requires the client to always access the same instance of a stateful session bean.
EJB containers provide an execution environment, in a server process, for EJBs. The Enterprise JavaBeans v1.1 Specification specifies contracts between clients and containers and between an EJB and its container. Part of the contract between the container and the client is the provision of a home for an EJB to which the client can go to create new EJB instances and to locate existing EJB instances. Part of the contract between an EJB and its container specifies methods that an EJB must implement to enable the container to provide a bean instance with access to container services and to issue notifications to the bean instance. These methods vary according to the type of bean. For example, two methods a stateful session bean must implement are ejbActivate( ) and ejbPassivate( ). ejbPassivate( ) is called on a bean instance when the container is about to passivate the bean instance by serializing it and writing it to disk. This may be done for a variety of reasons, such as the server process in which the bean was instantiated is running low on memory and/or the bean instance has not been accessed for a specified time period. However, because session beans can be transaction aware, the container cannot passivate a bean instance when it is taking part in a transaction. In the ejbPassivate( ) method the bean instance must ensure that its conversational state, which is at least partially held in memory, can survive passivation and so, for example, it must close any JDBC™ connections it has opened. Once a bean instance has been passivated it is reactivated by reading its serialized form from disk, de-serializing it, and then calling its ejbActivate( ) method. As a result, in the ejbActivate( ) method the bean instance might, for example, reopen any JDBC connections that were closed during passivation.
FIG. 2 is a schematic representation of the EJB programming model described. It shows an EJB server process (20) that provides an EJB container (201). For each EJB implemented an EJB Home (202) is provided which can be used by a client (10) to create an instance of that EJB (203). The EJB server process (20) may provide homes for many EJB implementations. An EJB instance (203) executes in the environment provided by the EJB container (201) and once an instance has been created, a client (10) can send requests to it. At any moment in time there can be many instances (204, 205) of the EJB that might have been created by the same or different clients.
FIGS. 3a and 3b are schematic representations of stateful session bean passivation and re-activation. FIG. 3a shows passivation of an instance of a stateful session bean named BeanCounter which maintains, in volatile memory, a counter of beans. During passivation the BeanCounter instance (302) is removed from volatile memory in EJBServer (20) and written to the bean store (303), on disk, in its serialized form (304). The serialized form contains the conversational state (beans=5) of BeanCounter instance (302). BeanCounter instance (302) is drawn with dashed lines to indicate that it is removed from volatile memory and at the end of passivation it only exists on disk in its serialized form (304). FIG. 3b shows re-activation which is the reverse of passivation. The serialized form of the bean instance (304) is read from disk and reactivated as BeanCounter instance (302). After re-activation the instance exists in volatile memory and contains the conversational state (beans=5) that it contained before passivation. The serialized form of the bean instance (304) may or may not exist on disk after this process.
It can now be seen that, in a workload managed system that uses the EJB programming model, the workload management unit must be sensitive to the type of EJBs that a client has previously accessed. For example, if a client only accesses stateless session bean instances, any request from a client can be allocated to any server process, in a workgroup, by the workload management unit, based on the chosen allocation policy. This is because these beans do not contain conversational state. If a client accesses entity bean instances they can also move server process, but only between transactions, because entity beans maintain state in a database and are transactional. However, if a client creates and accesses a stateful session bean instance, because the instance may contain conversational state in volatile memory, the client will assume an affinity with the server process in which the bean was created, for the lifetime of the client, such that all subsequent requests from the client to the bean instance are given to the same server process. If the bean is passivated between requests, the bean is reactivated in the server process when the first request after passivation is received.
One example of a product that provides a workload managed system that uses the EJB programming model is the BEA Weblogic Server™ 6.0 product of BEA Systems, Inc. This product refers to workgroups as Server Clusters. Workload management is provided in two forms. EJB home objects can have a cluster-aware home stub that has knowledge of all EJBHome objects on all server processes in the cluster. This stub provides workload balancing for client requests to create and find EJB instances. EJBs can have a replica-aware EJBObject stub that maintains knowledge of all copies of the EJB that reside on server processes in the cluster. The EJBObject stub provides load balancing and fail-over services for EJB method calls. Stateless session beans can be replica-aware and have cluster-aware homes, such that all requests to create and access stateless session bean instances can be workload managed. However, stateful session beans can only have cluster aware homes and so only calls to create stateful session beans can be workload managed. All requests to a stateful session bean instance are generally given to the same server process. One exception to this is provided using in-memory replication of stateful session bean instances. With in-memory replication the stateful session bean is given a cut-down replica aware object stub that maintains a primary server process instance on which the bean instance runs, and a secondary server process instance to use for replicating the bean's state. Now if a client modifies the bean instance's state under the scope of a transaction, when the transaction is committed the bean instance's state is replicated in volatile memory in the secondary server process. Should the primary server process of the bean instance fail, a client request is re-routed to the secondary server process, which becomes the primary server process, and a new secondary server process is allocated from the cluster. In this situation the client automatically gets access to the last committed state of the bean. This provides fail-over support for stateful session beans rather than workload management, and requires the server to co-ordinate deletion of the in-memory copy of the bean instance. It can also be seen that if a stateful session EJB instance has been modified in an incomplete transaction, when the primary server fails, the next request to the EJB instance will not fail but will lose the uncommitted change. As a result a client can never be sure whether a stateful session bean instance has lost uncommitted updates.